It's not clear to me that we should be tolerating strings containing numbers to be used as keys into Arays here.

From reading our APi docs and types, I would not expect this to be supported.

@CraigMacomber I can remove this support, but I'm wondering how consistent we've been in this regard. ArrayNode's get explicitly does support this. Seems odd to me that we wouldn't support it here.

Actually, I don't think that's what we want. POJO arrays allow both (implicitly numbers), and POJO objects allow both (implicitly strings), so it seems like we should follow suit.

https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAhgJwXAngLhmArgWwEYCmCA2gLowC8MxAjADQBMdAzKQNwBQHokIANgQB0fEAHMAFImQpiABlIBKNjAD0KmDW7gI-ISIlTUxAESzji5Wo1ctkWADMQISjADeHGJ5iyMxgBIEfCLGdBwAvpy2OgLCYuKOIHIWqur+gcFRurESCSZmyVZpQSDGNkA

Maps are an exception here. And maybe we want to only allow string keys for those. But since we strictly support string keys in our maps, matching the policy for Objects may make more sense.

Shouldn't we just preserve current behavior? I think the current behavior is that numbers are allowed for arrays, but not for objects and maps.

Note that number keys are allowed when accessing Object node properties (though not Map node properties). E.g.

class TestObject extends schema.object("TestObject", {
	"0": schema.string,
}) {}
const test = new TestObject({
	0: "Hello world!"
});

const zero = test[0]; // "Hello world!"

So, what I have is consistent with our standard property access for Arrays and Objects. And this is consistent with POJO. So, I'm pretty strongly convinced that deviating from this would be a bad idea.

With the exception of Map nodes. I think there is room for longer term discussion about maybe allowing use of numeric keys with our maps, since they strictly support string keys. But for now, that isn't supported, so it makes the most sense to be consistent with that.

It is literally impossible to implement arrays without supporting string keys, since JavaScript does not support numeric keys: they are stringified. The property key received by a proxy can never be a number: it is always a string, even when the user provides a number.

Our arrays support string keys exactly the same as JavaScript arrays, meaning we use typescript to tell you to pass in a number, which JS converts to a string behind the scenes. We do not support strings in places where not supporting strings is possible, for example in "at".

Our code for converting string indexes back to numbers exists to make indexing with numbers work: the fact indexing with strings works is an unfortunate side effect of this very questionable language.

For example ["x"]["0"] gives "x" just like ["x"][0] does, and the proxy can't tell those two lookups apart as both search for a member under the key "0". Note that this also gives "x": {"0": "x"}[0] : this conversion from number to string is a JS property thing, and has nothing to do with arrays.

I think my main point can be summed up by the following:

Array nodes can be indexed using string-formatted integer keys, so I don't think it makes sense for them not to work via child.

class MyArray extends schemaFactory.array("my-array", schemaFactory.string) {}
const myArray = new MyArray(["Hello world"]);
myArray["0"]; // "Hello world"
Tree.child(myArray, "0"); // Should match

• Similarly, for object nodes, we support indexing them with numeric keys, so the behavior of child should match.

class MyObject extends schema.object("MyObject", {
	"1": SchemaFactory.optional(schema.string),
}) {}
const myObject = new MyObject({ 1: "Hello world" });

myObject[1]; // "Hello world"
TreeAlpha.child(myObject, 1); // Should match

Maps are a different story, and child already rejects number keys for them. But I think we need the above support for Arrays and Objects (and soon, Records).

FWIW, @Josmithr and I talked offline and I think the idea of consistency with POJO is compelling. I strongly disagree with the idea of possibly wanting maps to support something similar, as I think a very important property of maps is that keys that compare equal should look up the same value, and keys that do not should not. If we break that contract, I think this would be a massive bug pit, and I don't see any offsetting reason to do so. Setting that aside, I'll vote in favor of consistency with POJO :)